The ATLAS Tile Calorimeter Test Beam 
Monitoring Program 

Paolo Adragna, Andrea Dotti, Chiara Roda 
Universita di Pisa e 
Istituto Nazionale di Fisica Nucleare, Sezione di Pisa 

Abstract 

During 2003 test beam session for ATLAS Tile Calorimeter a moni- 
toring program has been developed to ease the setup of correct running 
condition and the assessment of data quality. The program has been 
built using the Online Software services provided by the ATLAS Online 
Software group. The first part of this note contains a brief overview of 
these services followed by the full description of Tile Calorimeter mon- 
itoring program architecture and features. Performances and future 
upgrades are discussed in the final part of this note. 

1 Introduction 

The monitoring program described here has been developed in the frame- 
work of the calibration Test Beam periods carried out at CERN on ATLAS 
Tile Calorimeter. The ATLAS calorimetric system is a composite detector 
which exploits different techniques at different rapidity regions to optimize 
the calorimeter performance while maintaining a high enough radiation re- 
sistance. The Tile sampling calorimeter (TileCal) is the central hadronic 
section of this system. It consists of three longitudinal samplings of iron 
plates and scintillating tiles. TileCal is composed by one central barrel and 
two side (extended) barrels consisting of 64 modules each. During the three- 
year calibration program about 12% of these modules have been exposed to 
test beams. 

The monitoring program described here (in the following referred to as 
PMP) has been developed for the 2003 Test Beam period. This application, 
based on ROOT and on the software developed by the ATLAS Online 
Software Group, allows to monitor both Tile Calorimeter modules and beam 
detector data. This program has allowed to obtain a fast setup of beam 
conditions as well as a fast check of the calorimeter data quality. 

A short account of the software environment where the program has 
been developed and a detailed description of the TileCal Monitoring Task 
are given in the second and third section respectively. 
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2 General feature of monitoring applications 



Atlas Online Software provides a number of services which can be used to 
build a monitoring system [2]. Their main task is to carry requests about 
monitoring data (e.g. request of event blocks, request of histograms...) from 
monitoring destinations to monitoring sources and then the actual monitored 
data (e.g. event blocks, histograms...) back from sources to destinations. Four 
services are provided to access different types of information [31 S El El : 

• Event Monitoring Service; 

• Information Service; 

• Histogramming Service; 

• Error Reporting System. 

PMP uses the Event Monitoring Service while other services will be included 
in future upgrades. 



C \ 

ROD 




r \ 

ROS 




f \ 
SFI 




f \ 
EF 






Event 


Event Distribution 






Event 




Event Display 



Monitoring Task 



Event Dump 



Figure 1: Structure of the Event Monitoring Service J^. 

The Event Monitoring Service (EMS) provides events to the User Moni- 
toring task sampling them from any point of the data flow chain. The system, 
shown on figure Q consists of the following subsystems [7]: 

• the Event Sampler, which is responsible for sampling event data flow- 
ing through the DAQ system and for storing them in the Event Dis- 
tribution subsystem; 
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• the Event Distribution, which is responsible of the distribution, on 
demand; 

• the User Monitoring Task, which requests events through the Event 
Iterator. 

The implementation of the User Monitoring Task is described in detail 
in the following sections. 



3 The TileCal monitoring task 

The TileCal Test Beam monitoring program is an object oriented applica- 
tion developed in C++. It is completely based on the ROOT framework 
and in particular data storage, graphical user interface and event handling 
fully exploit the use of ROOT classes and methods. The program has been 
developed under Linux operating system for the i686 architecture. In figure 
12 the code working diagram is drawn 9 . 
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Figure 2: Schematic structure of the Tile Calorimeter monitoring program. 

The input to PMP may be either raw data files stored on disk or online 
sampled events provided by the Event Distribution. In both cases data are 
expected to be written in the standard ATLAS format |1U| . 

Once the event is accessed, data are unpacked and interpreted. Event un- 
packing proceeds through detector independent methods up to the localiza- 
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tion of the Read Out Driver (ROD) Fragments. Detector dependent methods 
are implemented for the extraction of data inside this fragment. Each event 
contains both Tile Calorimeter and beam detector data (Cerenkov counters, 
scintillators and wire chambers). All relevant information is extracted, event 
by event, and stored in a ROOT Tree residing in memory, while raw 
data are discarded and the buffer is freed. From this point on the analysis 
is performed using only data stored in the ROOT Tree. Histograms pro- 
duced during the analysis can be immediately displayed using the presenter 
included inside the Graphical User Interface (GUI). 

The possibility of reading raw data files from disk not only greatly sim- 
plifies the debugging process but also allows to run simple analysis tasks on 
the just acquired data. 

3.1 Monitoring program architecture 

The best way of explaining PMP architecture is probably to follow the path 
a typical user would walk on to work with the application 12 J. As shown in 
the dependency diagram of figure PMP abstract structure is divided into 
three main blocks. 
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Figure 3: Dependency Diagram for PMP classes. 



The first block, named in figure as Data Source, includes the classes 
DataFile and Consumer which are responsible for fetching a buffer of 
data from the selected source. 

The buffer memory address is passed to the Unpacking and Decode block 
by the class DataConnection. The task of this second block is to extract 
the fragments needed and to interpret them. 

The third block, the Presenter, fetches the histograms produced and 
filled by DataBase and organizes their graphical display into tabs. This 
block is also responsible for managing the user required actions. 
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The main panel 

When the program is started the main panel (figure EJ) is created. 
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Figure 4: Main control Panel of PMP. 



It is built by an instance of the class MainFrame that, apart from 
drawing the GUI, is also responsible for the event handling and for the 
subsequent actions. From this stage on the user can completely drive the 
application (e.g. choose the trigger type and the data input source, opening 
the presenter...). The event access is implemented using the classes DataFile 
and Consumer for event retrieving either from data file or from online 
Event Monitoring Service respectively. In both cases a full event is buffered 
in memory and passed to the unpacking and decoding phase. 



Unpacking and decoding 

The event is structured according to the ATLAS event format: the detector 
data is encapsulated into 4 layers of headers, all having similar structures. 
In order to easily reach the detector data five classes have been developed: 

• RawAtlasEvent 

• SubDetectorFragment 

• ROSFragment 

• ROBFragment 

• RODFragment 

Their algorithms allow to identify the corresponding block of data and 
their fields. These classes are implemented in such a way that a call to the 
method RawAtlasEvent::ReadFromMem triggers the complete event 



5 











.J- n * 


Eea 


-ii Counte 


$ | Cherenkov ] Drawer ] 


Event Display ] Samples ] 





Scintillator 1 




Figure 5: Example of a set of PMP histograms as they appear in the Presenter. 

decoding: in fact this method calls SubDetectorFragment::ReadFrom- 
Mem for every SubDetector block of data, every SubDetectorFragment::- 
ReadFromMem calls ROSFragment::ReadFromMem for every ROS 
block and so on. 

The modularity of this structure allows to easily add sub-detectors man- 
aging the decoding of their new data format just by including the appropriate 
Decoding routine. 

Once the whole chain has been executed the pointers to all RODs in the 
event are stored in a vector. The decoding of the detector dependent data is 
managed by the method RawData::Decode which determines the correct 
unpacking algorithm for each subsystem on the base of the ROD id value 
(every ROD, and consequently every kind of data, is identified by a unique 
number indicated as source identifier). 

ROOT Tree 

Once fully unpacked, data are stored in a ROOT Tree and the raw data 
buffer is freed. The tree structure is created on the base of the event struc- 
ture. Since this one is not known before starting a data taking (for example 
the number of detectors may change in different data takings) the tree ar- 
rangement is built according to the structure of the first retrieved event. 
The data stored in the the ROOT Tree is then used for simple analysis and 
to fill histograms. 

The Tree normally acts as an interface between the data decoding and 
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Figure 6: Example of event display. The figure shows a representation of the energy 
released inside Tile Calorimeter Modules by a pion, impinging at i] = 0.35 and 
producing a signal in cells A^, BC4, D4- 

the analysis phase where histograms are filled; however it allows also to save 
a complete collection of sampled and preprocessed events on disk for a more 
in-depth analysis with standard ROOT tools. 

Presenter 

The list of created histograms is stored inside an instance of the class 
DataBase. Histograms can be viewed with a simple presenter in a separate 
window. Different graphical sections lay on the same display. Within each 
section, plots are drawn in different embedded canvas whose coexistence is 
granted using ROOT's capabilities of organizing graphic widgets into a table 
layout jllj (figure |SJ). The presenter refers to the class database to get the 
appropriate histograms to be displayed. The use of the TQObject ROOT 
class and the Signal - Slot mechanism ^3] allows to plot histograms in real 
time and to refresh each canvas independently. 

The Signal - Slot mechanism has also been applied to the implementation 



7 



of histogram rebinning and resetting. Each histogram is associated with a 
set of buttons, clicking each of them causes the emission of a signal. The 
latter is caught by DataBase which performs the appropriate action. 

PMP displays plots relative to the beam detectors (Cerenkov counters, 
beam profile, coincidence scintillators) and to TileCal modules. 

Among the different plots there is a simple event display where the energy 
deposited in each cell of the three calorimeter modules is shown (figure EJ). 

Here the three modules of Test Beam setup are represented as two di- 
mensional histograms, while each calorimeter cell is drawn as a single par- 
allelepiped with height proportional to energy deposit. On the axes one can 
read the r/ value and the depth (the three longitudinal layers denoted A, 
BC, D) of the signal. 

On all the displayed histograms it is possible to perform standard ROOT 
actions (rescaling, fitting, ...). 



4 Program performances 

The monitoring program has been extensively tested to check the usage of 
CPU and memory during the data taking periods at Test Beam. The test 
is performed on a Pentiumlll class machine at 1GHz with 256 MB of RAM 
running Linux RedHat 7.3 (CERN version). 

The mean CPU load is 41% while the average usage of physical memory 
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Figure 7: PMP Memory usage (physical plus swap) as function of running time. 
The total memory (physical plus swap) usage is shown in fig. [7| as a 



function of running time. The steep increase of used memory, shown on the 
plot around 550 seconds, represents the opening of the presenter GUI. 

The monitoring of the memory usage has proved to be an important tool 
to find and correct memory leaks during the development. 



5 Future plans and conclusions 

Although the program is quite flexible from the maintenance point of view, 
thanks to its high modularity and the use of ROOT Tree to decouple un- 
packing from histogramming, it still suffers from lack of optimization which 
limit some aspects of his performance. 

The main problem is speed. PMP keeps on making remarkable efforts to 
transform raw data into values ready-to-use for analysis and plotting, but 
his single-threaded configuration is quite penalizing. In particular situation 
of CPU overloading, the execution of the graphical presenter code lowers 
the performances considerably. 

To solve this problem we plan to split the graphical part from the compu- 
tational one, switching to a client-server configuration. The computational 
part which will unpack, decode and fill the required histograms, will transfer 
the filled histograms to the Histogramming Service provided by the Online 
Software Group. The graphical part will fetch histograms from this service 
and will display them. The graphical part will be configurable in order to 
be easily used both for different detectors and for a combined run. 
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Figure 8: Number of hits recorded by the first Muon Chamber (MDT) versus total 
deposited energy in the hadronic Tile Calorimeter obtained from data recorded at 
Combined Test beam during September 2003. The two populated regions on the top 
left and on the low right regions correspond to muons and pions respectively. 
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A first look at the possibilities of upgrading the monitoring program 
here discussed to monitor a larger set of detectors has been tried at the 
combined Test Beam in September 2003. MDT and SCT were simply in- 
cluded using their standard data decoding routines. This allowed to obtain 
simple online histograms showing correlated information from different de- 
tectors (Figure EJ). 

This experience has allowed to better understand bad and good features 
of the present program and has helped us to plan the future program struc- 
tures. It is foreseen to test the future versions of the monitoring program 
during the 2004 Combined Test Beam. 
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